perm filename RICART.MSG[LET,JMC] blob
sn#259356 filedate 1977-01-20 generic text, type C, neo UTF8
COMMENT ā VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ā17-Jan-77 2017 DGR via NBST Dialnet
C00011 ENDMK
Cā;
ā17-Jan-77 2017 DGR via NBST Dialnet
Thanks for the writeup on DIALNET. Your proposal that DECUS
co-operate in implementing Dialnet is accepted. I'm the DECUS
Networking and Communications Working Group Chairman when
I'm not wearing other hats, so that makes it official.
I didn't bother to consult anybody else yet (although I am sure there will
be great enthusiasm from some) because I am personally interesetted
in such a project.
At the National Institutes of Health, we have found a need for
occasional PDP-11 to DEC-10 communications of relatively low volume
if it were to be achieved at low cost. Therefore, Keith Gorlen and I
have written what we call CLINK (Communications LINK)--a set of software
in BLISS that implements the DDCMP error detection/retransmission
protocol and an ad hoc version of DAP, a data access protocol.
The programs run in user mode on both machines, and hence
do not have to be resident. The hardware used is simple, inexpensive
asynchronous lines. The PDP-11 user dials any DEC-10
timesharing port, uses a virtual termilnal mode to LOGIN, and then
invokes the DEC-10 program which in turn sends a DDCMP START message
to the 11 to get it fired up running DDCMP. They then transfer
files between the two machines.
One of the things in the back of my mind has been that CLINK can
be adopted for DEC-10 to DEC-10 or PDP-11 to PDP-11 communications without
any major work since the source for the two ends is mostly in common.
Most people use CLINK with Vadic 3405 modems (1200/1200 baud) and
get about 700+ useful bits of data per second over the link.
I have also arranged for a dialer on a Bell 100-series line for attempting
DEC-=10 to DEC-10 communications but have not had the time to get the
dialer working.
I envision DECUS discussions taking place through teleconferencing and mail
messages over a network with single links that come at night and disappear
after the day's traffic is done. I see users submitting problems to DEC
online. I see software distribution taking place to your machine overnight.
I see the DECUS library as being accessible on-line. Etc. of course.
My thinking follows very closely the lines that you have written in
Section 1. "The DIALNET Idea". Some of the ideas in section 2. "Scenario"
go beyond what I had considered (those are (a) terminal linking, but this
is a good idea (b) footnoting, I have often wondered what a good way would
be to do this, but had always given up as to ohard to implement, and (c)
running programs on a remote computer, because of the dissiculty in
charging for the time). A comment on 3, standardization. If you
would like, DECUS has a liason to the ANSI x group and could be used to
help promolgate a standard.
Issues: What error correction facilities are required? DDCMP
What is the trade-off between buffer size and compute time? My first reaction
is not to worry about it, but measure it later and then use the
best size for the machine you are on. The network should accpt varying sizes.
Can dial-up communications rates meet most of the needs for computers
belonging to different research organizations? An imponderable question, but
we have found that it suffices for a large fraction of people with their "own"
PDP-11s who want to talk to our 10.
What is the best way to handle the fact that different modem speeds have
different prices. ? Select lowest common demoninator and allow higher speeds as options. The higher speed formats are not widely agreed upon, and much
as I like the Vadic modem (we have several hundered here) you have 202-type
higher speed modems. (and there is a third entrant in this field now, as well as ell,
who will come out with their 212 modem).
What style of interaction is convenient? We can draw on the ARPAnet work,
and copy, or strike out on our own.
What is the status of the NSF proposal? What kind of SAIL support were
you envisioning for the project? There are some questions about the nature
of contributions that can be made by DECUS volunteers, and a positive
role needs to be defined. If I were going about it, I would suggest that
(1) some overall design work be done, (2) CLINK extended in several ways
to rpovide the DDCMP, (3) User interaction programs be written, (4)
Performance measurement and evaluation in a test environemnt, (5) Rework
based on four, and (6) global promulgation.
. . . .. Glenn
------------------
[McCarthy's reply to above message]
The NSF proposal has been submitted, and we expect a reaction soon.
As to modems, we need to evaluate price-performance of the modems,
and compare it with the cost of the rest of the project. Conceivably
we could work with a modem maker, if a new design would make it all
work much better, and it were judged that it wouldn't be relatively
too expensive for users. Les Earnest and/or I will react further to
your remarks, but needless to say, we welcome your co-operation. I
just received a letter from Bill Kiesewetter of D.E.C. offering their
help also.